ci: Start with a fresh build dir to ensure test dependencies are correct
We want to ensure that meson test just works, without having to redo the
whole dependencies setup phase, so let's just start a new fresh build dir
and run tests there
Ideally meson tests should just work without any pre-requisite build,
instead, we only need a configured build folder to work, but this does
not go as expected in gnome shell at the moment.
Since tests require generated files and compiled typelibs they don't
depend on, so just using `meson test -C build <test-name>` does not work
as expected.
So add test dependencies on test cases. We do not need to have per-test
dependencies right now since most of them share just the same
requirements, and this makes it easier to maintain
Currently the toolbox lacks malcontent >= 0.14.0, because that version
has not been released yet. However, we need it to test the upcoming
parental controls integration, so build it in the toolbox.
Pranav Jerry [Sun, 31 Aug 2025 14:09:02 +0000 (19:39 +0530)]
po/ml: Fix wrong calendar date formats
Closes: https://gitlab.gnome.org/Teams/Translation/ml/-/issues/1 Signed-off-by: Mohammed Sadiq <sadiq@sadiqpk.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3856>
Sebastian Wick [Mon, 8 Sep 2025 11:19:21 +0000 (13:19 +0200)]
brightnessManager: Handle absence of brightness control in _sync
We already call _sync in response to dimming changes, which might happen
no matter if we actually do have control over the brightness.
Let's just embrace _sync getting called in any situation and handle that
state gracefully by simply returning early. If we re-gain control, _sync
will be called again and the updated state becomes active.
An St.Button with toggle-mode ON would not update the toggle state when
invoked via keyboard input.
Fixes: dd694bf1a ("st/button: Use ClutterClickGesture instead of own button-press tracking")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3865>
Jonas Ådahl [Fri, 5 Sep 2025 13:53:52 +0000 (15:53 +0200)]
popupMenu: Queue relayout on popup menu parent when opening
The position of the menu depends on the position of the "source actor",
but the source actor is not a parent of the menu, but typically a
sibling.
Since we depend on the source actor position for placing the popup menu,
it's important that the source actor gets allocated before we allocate.
Currently the only way to ensure that the source actor is allocated
before the popup menu is by handling the layout via the parent actor, as
the order of the allocations done when queuing shallow relayouts is
currently undefined. As of d94638acae ("clutter/actor: Make child
position changes a noop when possible") in mutter,
Clutter.Actor.set_child_above_sibling() has a fast path when the
position doesn't change, which means the parent was did not get its
relayout queued. This caused the popup menu to end up being allocated
before the source actor, thus using an out of date source actor
allocation to base its position calculation on.
To fix this, queue a relayout on the parent actor unconditionally, after
inserting it into the parent actor, to let us be able to rely on the
source actor having been allocated before the popup menu itself getting
allocated.
Jonas Dreßler [Thu, 24 Jul 2025 16:27:29 +0000 (18:27 +0200)]
st/theme-context: Run dispose on theme nodes on theme context changes
When the theme context changes, we clear the theme cache and make the
widget tree throw away and create new theme nodes. That's because the
old theme nodes can no longer be used, they might be referencing old
CSS data, scale factors, or other things.
St itself should never reuse theme nodes after theme context changes,
but of course theme nodes are exposed to users of St, and they can
always keep a theme node around and call a method on it even after a
theme context change.
To avoid those outdated theme nodes accessing outdated pointers into
the Croco structures and causing crashes, force-run their `dispose()`
function when the theme context changes. This should ensure that all
problematic pointers in the theme nodes are cleared, and users of St
can't crash gnome-shell.
Jonas Dreßler [Thu, 24 Jul 2025 17:47:58 +0000 (19:47 +0200)]
st/theme-node: Free properties array on dispose rather than finalize
We're going to use `g_object_run_dispose()` on StThemeNode with the next
commit in order to manually clear the properties array and a few other
things when the StThemeContext changes.
That's because after theme context changes, the CSS properties will no
longer be valid, and accessing them will cause crashes. Even if St behaves
nicely and throws out all theme nodes on theme context changes, there
might still be users holding references to nodes, so we want to ensure that
the old nodes are harmless after theme context changes.
Jonas Dreßler [Thu, 24 Jul 2025 16:51:25 +0000 (18:51 +0200)]
st/widget: Don't animate theme node updates on theme context changes
With commit 4dfa39457e, I was assuming that emitting `::changed` on the
StThemeContext, triggering StWidgets recursive style-changed machinery,
is enough to get rid of all the theme nodes that are in use, ensuring
they're never accessed again after the `::changed` emission.
That assumption turned out to be wrong: `st_widget_recompute_style()`
animates updates of theme nodes using StThemeNodeTransition, and
StThemeNodeTransition keeps the old theme node around, accessing it at
various later points. This caused various crashes on extension
loading/unloading, because that triggers a theme context change, where
a StThemeNodeTransition would later access an outdated theme node,
pointing to CSS properties that are already freed.
That said, reverting 4dfa39457e doesn't seem like the best idea,
because other calls to `st_theme_context_changed()` also seem to make
the same (incorrect) assumption, eg. `st_theme_context_set_theme()`
seems like a good candidate for a similar crash.
Probably St just shouldn't try to animate on theme context changes: The
old theme nodes are no longer usable after those, but
StThemeNodeTransition expects them to be, so that's just a bad idea.
So change the style-changed machinery a bit to allow disabling transitions
and use that to avoid transitions on theme context changes.
Fixes: 4dfa39457e ("st/theme-context: Also remove theme nodes on stylesheet changes") Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7339
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3809>
status/network: Update Wi-Fi quicksettings icon on disconnect
Prior to this patch, upon a connected AP disconnecting from
the device, the current quicksettings wi-fi icon will continue
showing the "network-wireless-connected-symbolic" symbol in
the time between the initial disconnection and the adapter
deactivation, even though the connection has been
degraded by virtue of no longer being routable.
This will also happen in the
NM.ActiveConnectionState.DEACTIVATING state.
To make this clearer to the user, this change modifies
quicksettings' wifi icon to reflect the degraded states:
- An activated adapter with no active AP connection will
now map to the network-wireless-offline-symbolic icon
(to indicate that the AP signal is lost)
- NM.ActiveConnectionState.DEACTIVATING will now map to the
network-wireless-acquiring-symbolic icon (to indicate that
a state transition is in progress)
gdm/authPrompt: Preserve the text when switching entry visibility
The text visibility of an auth prompt entry may change dynamically at
runtime, in particular when unlocking the screen with the blank screen
or with the screen shield visible this is happening:
- The user starts typing the PAM credential (may be secret or not)
- Under the hood the PAM conversation starts and actually asks user
for input
- The entry text is not cleared because we use what the user has typed
so far as the preemptive secret.
- The entry is adjusted to follow the requested PAM text visibility
settings.
-> This may lead to switching the actual text entry widget in use
Now, if the first entry that PAM requires is "ECHO ON", like it may
happen in the case in which a visible value is requested, we end up
"clearing" what the user as typed instead of preserving the value as
pre-filled value.
Causing the user typing something wrong instead.
To prevent this we need to restore both the text, the cursor position
and the selection bounds (in case the use pressed some key [binding])
leading to a position or selection change.
In multi-factor authentication cases we may end up clearing the current
entry, but we are potentially leaving a previously filled inactive entry
as it is.
Avoid this, and clear all the entries we have when clearing the prompt.
gdm/authPrompt: Unset the entry reference on destruction
We use the internal entry as the reference to the text entry that is
currently in use, but during destruction we do not unset it, thus the
garbage collector may requires further cycles to actually release it.
Carlos Garnacho [Mon, 18 Aug 2025 16:59:49 +0000 (18:59 +0200)]
slider: Flip horizontal scroll coordinates in RTL languages
In those languages, the horizontal axis still grows positively
towards the right, which means we need to invert left and right
as they come from scroll events, in order to have the expected
effect.
Carlos Garnacho [Mon, 18 Aug 2025 16:55:32 +0000 (18:55 +0200)]
status/volume: Handle scroll events distinctly
Stop funneling the events to the (maybe hidden) volume
slider actor, and handle events directly at the volume
status icon.
This allows us to move it back to vertical motion, since
there are no cues to make us think scroll should be
horizontal here. The slider will still prefer horizontal
motion.
"Preserve battery health" is a new feature which limits battery
charging in order to increase battery longevity.
Currently when the charging limit is hit, the state is
indistinguishable from the unplugged, discharging state,
which isn't great: The user has no way to know whether
the limit was reached, or they accidentally unplugged
the device.
To address this, use dedicated icons in the plugged-in-
but-not-charging case.
Sebastian Keller [Thu, 21 Aug 2025 17:45:21 +0000 (19:45 +0200)]
st/private: Fix texture leak when creating shadow from actor
cogl_pipeline_set_layer_texture() adds its own ref to the texture in
_cogl_pipeline_set_layer_texture_data() when called via
_st_create_shadow_pipeline(), so the initial reference is leaked when
the pointer is stolen.
Fix this by not stealing the pointer, so autoptr can unref the texture.
Before the code was changed to autoptr in 71accdd97 the texture was also
manually unrefed after calling _st_create_shadow_pipeline().
Carlos Garnacho [Fri, 23 May 2025 09:12:20 +0000 (11:12 +0200)]
gdm: Drop explicit calls to sync_hover()
This was added in commit bfea41b771, together with some
manual hover/reactive state manipulation. The rest of the
calls went away, and crossing events came a long way since,
these explicit sync_hover() calls are not necessary anymore.
Jonas Dreßler [Fri, 1 Mar 2024 17:39:18 +0000 (18:39 +0100)]
st/focus-manager: Check for NULL instead of stage to exit loop
In st_focus_manager_stage_event() we get the current key-focus actor from
the stage, and then enter a loop where we iterate through parents until we
get to the stage. If the key-focus actor is not a descendent of the stage
for some reason, this loop will never exit and we've locked up.
We can easily prevent the endless loop by checking for NULL as the exit
condition instead of checking for the stage, so do that instead.
Jonas Dreßler [Sun, 13 Jul 2025 10:01:10 +0000 (12:01 +0200)]
switcherPopup: Move to a ClutterGesture for closing the popup
When the user presses a mouse button outside of the switcherPopup, the
popup should close. This broke when we moved StButton to ClutterGesture,
because the button_press_event() handler in switcherPopup will close the
popup before the click gesture recognizes.
Since we're trying to move away from direct event handling anyway, port
this functionality to a LongPressGesture with a duration of 0, so that
the popup closes immediately on button press as it used to.
Jonas Dreßler [Sat, 6 Aug 2022 12:46:50 +0000 (14:46 +0200)]
st/scroll-bar: Port scroll bar scrolling to use ClutterGesture
Avoid the troublesome event handling here and replace it with two
ClutterPanGestures, one for the trough and one for the handle.
This is a fairly non-intrusive port, there's room for a lot of
improvements, for example making the trough react to motion events too
should be fairly easy now.
Jonas Dreßler [Sat, 9 Aug 2025 17:40:54 +0000 (19:40 +0200)]
st/scroll-bar: Use an StWidget for the handle rather than a button
When we'll port the StScrollBar to use the new ClutterPanGesture, the
StButtons internal click gesture would interfere with the :active state of
the handle, because we set it in two places now: Here in StScrollBar, and in
StButton. Due to the order of gesture state changes when the scroll bar
handle pan gesture recognizes and cancels the button click gesture, the
active state will end up not being set during the actual pan.
To fix this, avoid using an StButton for the pan, and instead use a simple
StWidget.
While at it, change the CSS selector to be based on class name, not on ID.
IDs in CSS should be unique, and scroll bar handles are used more than once
in our UI.
Also, because apparently there's a Croco or St CSS parsing bug, select the
.vhandle/.hhandle class using the ">" child selector, as selecting just by
class doesn't do the trick :/
Jonas Dreßler [Sun, 10 Apr 2022 22:32:06 +0000 (00:32 +0200)]
Leave cancelling conflicting gestures to Clutters machinery
Since everything is a gesture now in the appDisplay, ClutterGesture will
do all the cancelling of other gesture by itself now, we merely have to
describe the relationship between them.
Jonas Dreßler [Wed, 3 Aug 2022 13:01:52 +0000 (15:01 +0200)]
dnd: Use ClutterGesture to start DnD interactions
With the last commit we introduced ShellDndStartGesture, so now port the
Draggable to actually use that gesture, and to move over to a ClutterGrab
once the DndStartGesture has recognized.
This is shuffling a lot of things around and removing quite a bit of code.
One thing to note is that to allow users of the DndStart gesture to specify
its relationship with other gestures (eg. to allow it run together with a
LongPressGesture), the DndStartGesture is exposed on the draggable as
the startGesture property.
Also, restore the integration with WindowPreview gestures, so all of them
are able to cooperate. This used to be done via addClickAction() in the past,
we can now specify this interaction to ClutterGesture.
Jonas Dreßler [Tue, 7 May 2024 17:07:06 +0000 (19:07 +0200)]
Add a ClutterGesture subclass for starting DND operations
Factor out the starting part of the DND operation from dnd.js and move it
into a new ClutterGesture subclass: ShellDndStartGesture
As with the previous port to ClutterGesture, this new gesture is written
in C due to performance concerns when we'll get rid of motion event
compression and start handling eg. 1000 HZ mouse events at the full rate.
This gesture now integrates with the ClutterGesture state tracking system
(giving us the benefit of coordinating with other gestures), and will
recognize (and also complete) as soon as a drag on a draggable actor should
start. As soon as that happens, the existing code in dnd.js takes over,
aquiring a (more exclusive) seat grab and handling things from there. This
porting of dnd.js will be done in the next commit.
Jonas Dreßler [Tue, 8 Jul 2025 14:58:25 +0000 (16:58 +0200)]
windowPreview: Replace the click action with a click and long press gesture
In the porting, temporarily stop integrating the WindowPreview gestures with
DnD, this used to be done through addClickAction() but DnD will change to
using gestures in later commits, making its porting moot. This integration
will be restored later on.
Jonas Dreßler [Fri, 25 Jul 2025 10:31:36 +0000 (12:31 +0200)]
edge-drag-gesture: Small improvements to gesture detection
Just a few small improvements to the accuracy of detection that came up
while porting to ClutterGesture.
- Use a fixed CANCEL_THRESHOLD instead of comparing the moved distance to
the perpendicular direction distance. Comparing to the perpendicular
distance means the point is basically allowed to travel in a max 45 degree
angle from the screen edge. Our EDGE_THRESHOLD is quite small though (20),
so after the gesture begins to recognize, it's surprisingly easy to
unwillingly cancel the gesture (just needs to move 20 pixels in the
perpendicular direction). Instead simply go with a fixed threshold for
cancelling the gesture. This has the additional upside that we'll also
move the state to CANCELLED if the gesture didn't move to RECOGNIZING
beforehand, a behavior that ClutterGesture strongly encourages.
- Introduce a cancel timeout of 200 ms, so that the gesture is cancelled
if it point is still hovering at the monitor edge for a while. The timeout
should be fairly short, as this gesture can happen on top of an application
window, and the application can't use the event until the gesture has moved
to CANCELLED, so we don't want to keep the event to ourselves for too
long.
Jonas Dreßler [Fri, 18 Mar 2022 15:25:38 +0000 (16:25 +0100)]
Port the EdgeDragAction to ClutterGesture
And since ClutterGestures will only be possible to implement in C (due to
performance concerns when we'll get rid of motion event compression and
start handling eg. 1000 HZ mouse events at the full rate), that means we
have to port the gesture to C!
It behaves mostly the same still: It's a single finger touch-only gesture
that recognizes as soon as a point that began on the monitor edge moves away
from that edge. It then emits "progress" signals with the distance from the
edge all the way until the fixed threshold distance (DRAG_DISTANCE) is
reached, where it then moves to COMPLETED.
There's definitely room for further improvements here, eg. the gesture
should probably only complete once the point is lifted from the screen.
Jonas Dreßler [Tue, 30 Apr 2024 15:50:20 +0000 (17:50 +0200)]
appDisplay: Remove action mode limitation for swipe tracker
Now that we no longer have the swipe tracker on the stage, but rather on
the actual actor that the gesture is happening on, we don't have to limit it
to specific ActionModes anymore, so remove that.
Jonas Dreßler [Thu, 31 Jul 2025 09:49:20 +0000 (11:49 +0200)]
Set debug names for swipe tracker pan gestures
Add a debug name param to swipe trackers to make gestures debugging
that sets the ClutterAction 'name' param of the pan gesture. This
should make debugging gestures easier when SwipeTrackers are involved.
Jonas Dreßler [Thu, 31 Jul 2025 09:43:57 +0000 (11:43 +0200)]
Set event phase to CAPTURE for swipe gestures starting in the session
When a swipe gesture can get triggered in the session (ie. on top of a
window, not just from the overview or other shell chrome), we want it to
receive events as soon as possible, as otherwise the clients will see
those events.
So use the CAPTURE phase for the overview gesture and the workspace
switching gesture, which makes sure the gesture sees each event before a
window gets to see it.
Jonas Dreßler [Thu, 31 Jul 2025 09:42:26 +0000 (11:42 +0200)]
swipeTracker: Port to use ClutterPanGesture
The new ClutterGesture subclass ClutterPanGesture fits the SwipeTracker
quite well. API wise the biggest difference to the TouchSwipeGesture it
was using before is that ClutterPanGesture has its own internal event
history to keep track of deltas and to calculate a velocity in the end.
That means we need to give it slighty special treatment right now, but
we'll improve that with the next commits.
So replace the internal TouchSwipeGesture and make the SwipeTracker use
ClutterPanGesture directly.
Jonas Dreßler [Sat, 31 Aug 2024 14:22:51 +0000 (16:22 +0200)]
st/button: Use ClutterClickGesture instead of own button-press tracking
Clutter has a gesture that can take care of this now, so get rid of all the
manual tracking of events let ClutterClickGesture handle it.
st_button_fake_release() is adapted to call clutter_gesture_cancel() until
everything is ported to ClutterGesture and Clutter will take care of this
automatically.
Jonas Dreßler [Fri, 18 Mar 2022 13:24:26 +0000 (14:24 +0100)]
unlockDialog: Move from TapAction to ClickGesture
ClutterClickGesture is a new subclass of ClutterGesture and implements
the same functionality as the TapAction and ClutterClickAction did,
which is why those will get removed. So move to ClutterClickGesture here
for the tap gesture.
tray/na-xembed: Destroy socket window when ending the embedding
Currently when embedding a tray icon is ended we are leaving the X11
socket window around as we don't really destroy it, while we're just
listening for its child destruction.
So, when embedding is ending we need to make sure that:
- If the plug window is still alive, move it back to its old parent
(normally that's the root window, but we query for it, to be sure)
- If the plug window has been already destroyed or reparented (by us or
by something else), we've to just destroy the socket window
tray/na-xembed: Use XShape to remove input on socket window
We don't want this window to take any input as, a part from blocking the
events on the shell representation itself, they may potentially make the
plugged window to do anything with the event is processing (such as
showing tooltips). And we don't want this since we only want to send to
those windows only the synthetic events that we explicitly control.
This was already the case before of commit ab60902058 but a similar
approach was not replicated, leading to input events being fully
processed from tray icons plugs.
It requires adding an explicit build dependency on Xext, but this is
something that mutter already depends on so not really a new dependency
unlockDialog: Do not reset the auth prompt on every tap
Currently we have a tap event tracker that causes that every time a tap
happens in the lock screen, we reset the auth prompt and this can be
particularly annoying at least in three cases:
1. Just clicking everywhere in the screen may lead the unlock entry
content to be cleared
2. Clicking in the screen while an authentication is in progress,
cancels it
3. This may break a multi-factor authentication method, as a single
click may lead previous steps to be cancelled
So, while resetting the auth prompt is important when we're about to
show it, it's not something we want to do while an authentication has
started.
As per this also do not touch the auth prompt sensitivity unless we're
in an idle phase, or we may end up overriding the auth prompt state,
leading for example to a text entry being editable while we're verifying
the secret
Takao Fujiwara [Wed, 27 Aug 2025 09:00:30 +0000 (18:00 +0900)]
ibusCandidatePopup: Fix scaling set-cursor-location-relative signal handling
Need to convert the raw coordinates to the scaled ones in gnome-shell.
IBus GtkIMModule can calculate the relative coordinates and gnome-shell
needs to provide the actual scale.
projects / gnome-shell.git / log